1. Field of the Invention
Apparatuses and methods consistent with the present application relate to managing resources in a Java environment. More particularly, apparatuses and methods consistent with the present invention relate to managing resources in a Java environment, in which in confirming finalized states of a plurality of reference objects and finalizable objects classified according to accessibility from a program to be currently executed, an order confirming whether the respective objects are finalized is changed, such that resources allocated to objects accessible through the reference objects are effectively used.
2. Description of the Related Art
Java is an object-oriented programming language that runs written code in a platform independent manner. Here, the platform means hardware on which a program executes, or a software environment, such as an operating system. The code written in Java is compiled into a Java byte code by a Java compiler. The Java byte code is executed by a Java virtual machine that is ported to a variety of hardware-based platforms.
FIG. 1 is a diagram illustrating a Java virtual machine according to the related art. A Java virtual machine 10 includes an interpreter 11, a garbage collector 12, a class loader 13, and a run-time system 14.
An instance for a class is referred to as an object. When one object is created, a portion of a heap region of a memory is allocated to the created object. In addition, when the corresponding object disappears, the garbage collector 12 releases the resource allocation of the corresponding memory region, such that another program or object can freely use the resource.
At the time of releasing the resource allocation, the garbage collector 12 confirms whether all objects to which memory resources of the heap regions have been allocated are finalized, and then releases the resources allocated to all of the finalized objects. In this case, the garbage collector 12 confirms whether access is possible from a program currently being executed so as to confirm whether the corresponding object is finalized. That is, the garbage collector 12 determines that accessible objects through a root set of a thread are not finalized, and determines that inaccessible objects through the root set of the thread are finalized.
There are objects that are accessible from the root set through an instance of a class (hereinafter, referred to as “reference object”) to which a reference class is inherited. These objects are classified into objects that are inaccessible from the root set, and the resource allocation for the corresponding memory region is released by the garbage collector 12.
In this case, the reference objects are classified into a soft reference object, a weak reference object, and a phantom reference object, and access to the objects may be classified into four types according to the access methods from the root set. That is, access to the objects are classified into access from the other objects excluding the reference object, access from the soft reference object, access from the weak reference object, and access from the phantom reference object.
FIG. 2 is a diagram illustrating a state in which objects are finalized according to the related art. The state includes a finalizable state 21, a finalizing state 22, a finalized state 23, and a returned state 24. The object in which a state change can be made is referred to as a finalizable object.
The finalizable state 21 means a state in which the object is created and being executed, the finalizing state 22 means a state in which the object is finalizing as a finalize function is executed, the finalized state 23 means a state in which the resource allocated to the corresponding object can be released by the garbage collector 12 as the execution of the finalize function is finalized, and the returned state 24 means a state in which the resources allocated to the corresponding object are released from the memory region.
In order to confirm whether the object to which the memory resource of the heap region is allocated is finalized, the garbage collector 12 sets all of the bits indicating whether the object is active (hereinafter, referred to as active bit) to false, and then starts to confirm all objects that are accessible from the route set. Then, if the object to be a confirm target is accessible from the route set, the garbage collector 12 sets the active bit of the corresponding object to true, and removes it from the resource releasing target.
A queue for each reference object may exist depending on whether a Java virtual machine is implemented. When the object to be the confirm target is accessible through the reference object, the garbage collector 12 inputs the address of the corresponding object to the queue corresponding to the type of the reference object. At this time, since the object accessible through the reference object is not a strongly accessible object, the active bit of the corresponding object is maintained as false.
When it is confirmed that the object is finalized, the garbage collector 12 inputs the address of the object, which is not strongly accessible, to the queue of the finalizable object.
In addition, the garbage collector 12 performs a resource releasing job for the objects corresponding to the collected addresses in the order of the queue of the soft reference object, the queue of the weak reference object, the queue of the finalizable object, and the queue of the phantom reference object. That is, the garbage collector 12 extracts the addresses input to the queue of the soft reference object, the queue of the weak reference object, and the queue of the phantom reference object, then sets the objects corresponding to the respective addresses to NULL, and sets active bits of the object corresponding to the address input to the queue of the finalizable object and all objects to be accessible from the object to true. This is because the objects finalized by the finalize function, that is, a finalizable object and the objects accessible by the finalizable object should be in an active state.
Meanwhile, when a certain object is a strongly accessible object and is an object accessible through the reference object (hereinafter, common object), the garbage collector 12 sets the common objects corresponding to the addresses extracted from the queue of the soft reference object and the queue of the weak reference object to NULL, and sets the active bit of the common object of the address extracted from the queue of the finalizable object to true. That is, after the same object (common object) is set to NULL, the active bit of the same object is set to true, and the memory resource allocated to the same object exists in a heap region. This state is maintained until the state of the object is a finalized state 23. Therefore, the memory resources that are not accessible through the reference object exist in the heap region resulting in wasted resources.
U.S. Pat. No. 6,070,173 discloses a method in which an actual object heap and a virtual object heap larger than the actual object heap are formed, a Java application object is allocated to the virtual object heap, and the garbage collection is performed in the virtual object heap.
However, according to the method disclosed in U.S. Pat. No. 6,070,173, since the heap region is virtually extended, there is no disclosure of a method preventing the generation of memory resources that are not accessible through the reference object.
Accordingly, a method has been strongly required where memory resources, which are not released in the resource releasing process by the garbage collector 12 and are not accessible, are prevented from being generated.